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that one or more component ATP requests 32 are rescheduled for later in the planning 
horizon or simply shorted. In one embodiment, LFM 22 and/or ATP servers 14 
monitors the status of component ATP requests 32 to identify such events and 
communicates accordingly with fulfillment server 16. As an example, ATP server 14 
might "publish" to LFM 22 and/or fulfillment server 16 the supply changes effecting 
the backlogged component ATP requests 32. If published to LFM 22, LFM 22 might 
then notify fulfillment server 16. Fulfillment server 16 might evaluate the revised 
component request status and act, for example, by notifying client 12 of the situation 
and providing one or more options to client 12. Similarly, changes made at 
fulfillment 16 server may need to be sent to the affected LFMs 22 and/or ATP servers 
14 so that they may adjust reservations of supply accordingly. Further, each of the 
workflows described above may support one or more alternative workflows to handle 
cases in which the ATP data components of system 10 have been working with 
becomes invalid due to such changes. 

Process ATP Server Changes [LFM] 

In one embodiment, system 10 provides an interface protocol between 
LFMs 22 and ATP servers 14 and/or between fulfillment server 16 and ATP servers 
14 such that planning changes affecting the promise characteristics of component 
ATP requests 32 in associated planning engines are proactively identified within ATP 
servers 14 and sent to LFMs 22 or fulfillment server 16 for evaluation. This 
evaluation processing is identical to that of the initial component promise response; 
that is, LFM 22 or fulfillment server 16 evaluates the changed component promise 
response according to the constraints specified in the originating ATP request 30. The 
revised promise from ATP server 14 may not change the commitment between the 
customer and the supplier. Since in one embodiment promise 46 and acceptance 50 
are distinct objects, a change to promise 46 does not change acceptance 50, which 
generally represents the binding business commitment between the customer and 
supplier. Schedule and other changes may be negotiated and resolved such that the 
original commitment can be kept. However, the binding business commitment does 
not change until client 12 or an associated user accepts the revised promise 62 and a 
new acceptance 64 is created. 
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Whether or not a planning change has affected the validity of the component 
promise 44, LFM 22 generates a planning change notification 60 for the change and 
may also note any failure conditions that exist. Planning change notification 60 is 
generated in a suitable format and sent to fulfillment server 16 using network 20. 
Planning change notification 60 may prompt fulfillment server 16 to generate a 
revised promise 62 and send it to client 12. Instead or in addition, fulfillment server 
16 may evaluate planning change notification 60 and generate one or more revised 
component ATP requests 66, which are sent to and processed at LFMs 22 in 
essentially the same manner as for the changed component ATP requests 32 described 
above. Fulfillment server 16 may act on planning change notification 60 in any 
appropriate manner according to the needs of clients 12 and associated customers and 
users. 

Process LFM Changes [Fulfillment Server] 

Fulfillment server 16 monitors and responds to LFM-initiated events such as 
component promise changes. Component promise changes within the planning 
engine associated with ATP server 14 may have substantially impacted the integrity 
of original promise 46. Therefore, in one embodiment, fulfillment server 16 re- 
evaluates promise 46 according to the constraints specified in the original ATP 
request 30. For example, depending on the value of the short proportional attribute 
associated with ATP request 30, fulfillment server 16 may adjust the promises of all 
request line-items proportionally and release the shorted allocations of other request 
line-items. Failing to do this might leave products tied up for the customer even 
though the customer would not ultimately accept those products. Fulfillment server 16 
may try one or more alternate suppliers before adjusting or failing ATP request 30, or 
may simply generate a suitable problem notice for client 12 or an associated user to 
review and resolve. 

Fulfillment server 16 may provide the capability to optionally re-price promise 
46 in the event of an LFM-initiated change, possibly determining whether any pricing 
calculations are necessary based on the nature of the change. For example, a change 
in the shipment date for ATP request 30 may not require re-pricing, while a change in 
the quantity may cause the promised price to be invalid. Instead or in addition, 
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fulfillment server 16 may provide the ability to re-calculate delivery dates based on 
LFM-initiated changes, possibly determining whether any delivery calculations are 
necessary based on the nature of the change. For example, a change in the quantity 
for ATP request 30 may not require delivery coordination, while a change in a 
shipment date may result in the promised delivery being invalid. 

When fulfillment server 16 has evaluated any changed component promises 44 
relative to the constraints specified in ATP request 30, fulfillment server 16 generates 
a revised promise 62 and sends it to client 12. This processing is identical to promise 
confirmation processing, except that original promise 46 already exists and fulfillment 
server 16 may only update the portions of promise 46 associated with the ATP request 
changes in generating revised promise 62. Failure notifications may be generated as 
appropriate. At this stage, client 12 or an associated user may wish to simply live 
with the changes, generating and sending acceptance 64 to fulfillment server 16, or 
proceed into a re-quote, change, or cancellation workflow. 

ATP Request Cancellation Workflow 

Initiate ATP Request Cancellation [Client] 

In one embodiment, client 12 or an associated user may be able to cancel an 
ATP request 30 at any point in its life cycle unless the supplier business constraints 
explicitly preclude it, for example, outside a specified time interval. As a result, ATP 
request 30 may be canceled during initial generation, during quotation processing, 
after acceptance, and even after partial fulfillment. The intent of cancellation is to 
make ATP request 30 permanently inactive. Client 12 or an associated user may 
query the ATP request 30 to initiate this processing. Once ATP request 30 has been 
displayed at client 12 through inquiry, the user may select a cancellation function to 
cause client 12 to execute the cancellation command. 

Process ATP Request Cancellation [Fulfillment Server] 

Fulfillment server 16 receives the request cancellation from client 12 in a form 
indicating that all the request line-items have been canceled. Fulfillment server 16 
next determines if there exist any product or supplier restrictions on cancellation. If 
so, a failure notification is immediately generated and sent to client 12 using network 



